Make Full and Empty generic over the error type
#85
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It is not uncommon to have a function that creatures a boxed body via
`Full` or `Empty`:
```rust
fn box_body_from_bytes(bytes: Bytes) -> UnsyncBoxBody<Bytes, Error> {
Full::new(bytes)
.map_err(|e| match e {})
.boxed_unsync()
}
```
The `.map_err(|e| match e {})` dance is necessary because `Full` always
uses `Infallible` as its error type, so we have to convert that into
whatever error type we actually need. This will often be hyper's,
tonic's, or axum's error type.
However if we make `Full` generic over the error type:
```rust
pub struct Full<D, E> { ... }
```
then Rust can just infer it and we avoid having to call `map_err`:
```rust
fn box_body_from_bytes(bytes: Bytes) -> UnsyncBoxBody<Bytes, Error> {
Full::new(bytes).boxed_unsync()
}
```
I think this is quite a bit nicer. It is especially nice that we avoid
having to type `match e {}` which is quite confusing unless you've see
it before.
The downside to this is that if the error type cannot be infered you
have to explicitly set it when creating a `Full`:
```rust
Full::<_, Error>::new(bytes)
```
That makes this a breaking change.
davidpdrsn
changed the title
Full's and Empty's error type genericFull and Empty generic over the error type
seanmonstar
reviewed
Feb 8, 2023
http-body-util/src/empty.rs
Outdated
| /// A body that is always empty. | ||
| pub struct Empty<D> { | ||
| _marker: PhantomData<fn() -> D>, | ||
| pub struct Empty<D, E> { |
There was a problem hiding this comment.
Probably worth discussing: what if it still had a default? Empty<D, E = Infallible>? It seems useful, but there's probably some cons to consider too.
There was a problem hiding this comment.
I think that makes sense!
|
I'm in favor of this; it'd make testing of functions that otherwise accept "production" types much more straighforward. With the addition of the default, would this be a breaking change? |
|
I think the default keeps it from being breaking. But it also means simply |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It is not uncommon to have a function that creatures a boxed body via
FullorEmpty:The
.map_err(|e| match e {})dance is necessary becauseFullalways usesInfallibleas its error type, so we have to convert that into whatever error type we actually need. This will often be hyper's, tonic's, or axum's error type.However if we make
Fullgeneric over the error type:then Rust can just infer it and we avoid having to call
map_err:I think this is quite a bit nicer. It is especially nice that we avoid having to type
match e {}which is quite confusing unless you've see it before.The downside to this is that if the error type cannot be infered you have to explicitly set it when creating a
Full:That makes this a breaking change.